1. Field of the Invention
This invention relates to improvements in computer memory management. More particularly, this invention relates to the determination of the amount of available memory in a running computer application.
2. Description of the Related Art
The terms Sun, Sun Microsystems, Java, J2ME, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States of America, and other countries. All other company and product names may be trademarks of their respective companies.
The Mobile Information Device Profile (MIDP) defines a set of Java application programming interfaces (APIs) that provide an application runtime environment for mobile information devices, such as cellular telephones. MIDP is defined in the document Mobile Information Device Profile (JSR-37), JCP Specification, Java 2 Platform, Micro Edition, 1.0a (Sun Micro-system Inc., Palo Alto, Calif., December 2000), which is incorporated herein by reference. MIDP builds on the Connected Limited Device Configuration (CLDC) of the Java 2 Platform, Micro Edition (J2ME). MIDP applications that use the MIDP and CLDC APIs are known as MIDlets.
Mobile information devices typically have a very small memory, low-speed graphics, and slow communications performance, when compared with personal computers (PCs). While programmers commonly develop applications using personal computers as development platforms, the memory and speed limitations of the target mobile information devices must be taken into account in order for the applications to run satisfactorily on the target devices. In particular, the memory capacity in mobile information devices is often a limiting factor in program development.
In early programming languages, memory allocation and deallocation was a burden imposed directly on the programmer, who was responsible to allocate and deallocate memory blocks. This burden was essentially eliminated over 40 years ago by the invention of garbage collectors, which are programs that deallocate memory that is assigned to dead or unreachable objects. Garbage collectors have greatly improved programmer productivity, and have enhanced software reliability. They are supported by modern programming languages, such as Java. A variety of different garbage collection techniques is now known in the art.
In general it is not possible for a garbage collector to determine exactly which objects are still live. It is commonly assumed by implementers of garbage collection routines that a live object is reachable or can be proven to be referenced. Nevertheless, the inability to guarantee that an object is live inconveniences a program developer who is working in an environment in which memory is a limiting resource. As supported in most languages, garbage collection is an asynchronous process. It is typically invoked automatically by the computer system at runtime when the amount of memory allocated by the running program reaches some limit, which depends on the amount of memory actually available in the system. Therefore, the developer is generally unable to determine at any particular point in the execution of the application how much of the memory allocated to the application is actually required, and how much is merely preempted by objects that are no longer reachable. Furthermore, it is often desirable to reduce the memory requirement of an application at critical points in its execution. At present, this cannot be done deterministically in the context of small wireless devices, such as cellular telephones, using current garbage collection techniques.
In accordance with a disclosed embodiment of the invention, a developer is enabled to determine the maximum amount of memory that is consumed by a running application at any point of its execution. The system garbage collector executes between designated pairs of program instructions or statements. The amount of memory used by the application is known after each such program instruction or statement, and is equal to its theoretical requirement. In one embodiment the system garbage collector executes between all pairs of program instructions or statements in a designated range, which can be the entire application.
A developer of an application for a device with a small memory, such as a MIDP device, can use this feature of the present invention to tailor the memory requirements of the application to comply with the memory limitations of the device, even when the developer is writing the application on a workstation with a much larger memory.
The invention provides a method for evaluating maximum memory requirements of a computer application on a development platform, which is carried out by executing a sequence of program instructions in the application, running a garbage collector following execution of at least designated ones of the program instructions to free a portion of a heap memory that is no longer in use. After running the garbage collector the method is further carried out by determining a current size of the heap memory, comparing the current size of the heap memory with a previous maximum size of the heap memory, and responsively to the comparison, memorizing a current maximum size of the heap memory.
In one aspect of the method the garbage collector is run following execution of each of the program instructions in the sequence.
According to an additional aspect of the method, the program instructions are software code.
According to still another aspect of the method, the program instructions are embedded in a hardware device.
In yet another aspect of the method the current size of the heap memory is added to a plot on a screen display.
According to a further aspect of the method, the application is a MIDlet adapted to execute on a mobile information device.
According to another aspect of the method, the mobile information device is MIDP compliant.
One aspect of the method includes determining whether the current size of the heap memory exceeds a predetermined value.
The invention provides a computer software product, including a computer-readable medium in which computer program instructions are stored, which instructions, when read by a computer, cause the computer to perform a method, which is carried out by executing a sequence of the program instructions of an application, running a garbage collector following execution of at least designated ones of the program instructions to free a portion of a heap memory that can no longer be used. After running the garbage collector, the method is further carried out by determining a current size of the heap memory, comparing the current size of the heap memory with a previous maximum size of the heap memory, and responsively to the comparison, memorizing a current maximum size of the heap memory.
In an aspect of the computer software product the garbage collector is run following execution of each of the program instructions in the sequence.
Another aspect of the computer software product includes determining whether the current size of the heap memory exceeds a predetermined value.
The invention provides a development system for evaluating memory requirements of a computer application, including a user interface adapted for executing code of the application, wherein the user interface is further adapted for identification of a range of successive locations in the code at which garbage collection is to be performed. The development system further includes a memory storing a maximal value of a heap, and containing a data structure, the data structure including computer instructions that are invokable via the user interface for allocation of the heap, including a first instruction to invoke a garbage collector for the heap when instructions of the range are is executed, a second instruction to return a current size of the heap that is still is used by the application, and a third instruction for storing a larger value of the stored maximal value and the current size in the location.
According to an additional aspect of the development system, the code is software code.
According to still another aspect of the development system, the code is stored in hardware.
According to yet another aspect of the development system, the user interface has a program for plotting the current size on a screen display.
According to a further aspect of the development system, the application is a MIDlet adapted to execute on a mobile information device.
According to another aspect of the development system, the mobile information device is MIDP compliant.
According to one aspect of the development system, the data structure includes a program that reports a determination whether the current size of the heap exceeds a predetermined value.